Re: So what next?

Egbert Eich <eich-u7BhqnqprCWvj1b/[email protected]>
Newsgroups gmane.comp.freedesktop.release-wranglers
Message-ID <[email protected]>
Keith Packard writes:
 > 
 > Around 18 o'clock on Apr 8, Egbert Eich wrote:
 > 
 > > I would like to do the merge of RELEASE-1 before the other merge.
 > > I've set a base tag to simplify this, and I'm afraid this will not
 > > work if we merge to head first.
 > 
 > Yes, I was wrong -- this is clearly the right order.  We need to appoint 
 > someone to do this task; it isn't something which can be shared.  I think 
 > it should be either you (Egbert) or I as we have more complete knowledge 
 > about how RELEASE-1 was hacked together.

I will do a merge of the branches today. I'll test and announce it
before doing the commit.
I have noticed that people have been starting to create branches
on the RELEASE-1 branch.
Except for special purposes (like the TM branch) this should *not*
happen.
Also we need to document a branching policy on our Wiki
and need to have an area where each branch is described.
Here I'm thinking of a central page containing 
1. the branch names of *active* branches, 
2. a short description 
3. a list of names of the branch maintainer(s)
4. if applicable a link to further information on the project.
   Once a branch is no longer in use this information should be 
   moved to someplace else.


 > 
 > > I certainly would not mind to have the ongoing development taking 
 > > place in HEAD. XFree86 moved to this structure years ago and I know
 > > nothing that would speak against it.
 > 
 > Once XORG-CURRENT is really current, then moving that to HEAD should be 
 > simple.  I think we have rough concensus that this is the right thing to 
 > do.

Yes, I just need to figure out how to do it.

 > 
 > > This gives no value to the user and just delays things.
 > > We need to get technology out to remain credible.
 > 
 > I believe we will not have concensus on this issue anytime soon and that we
 > need a formal conflict resolution process here.
 > 
 > I'm feel strongly that now is the best time to make the migration to a
 > modular build system, and that separating the build system transition from
 > any technical changes will give people the greatest confidence in the new
 > system.  Doing that transition at the same time we add a bunch of new code
 > will be very hard on everyone.

I'm not so sure about this. I'm not even sure if there is a consensus
how the build system will look like. Some people have proposed a new
build system. 
Speaking of myself I have issues with this build system. Contrary to
what has been promised I have *not* received a satisfactory answer to
my questions.
The following answers do *not* qualify as satisfactory:
1. "Some people may loose but think of the benefit for the others."
2. "I don't know off hand how to do this we should take a closer
   look at the documentation."
3. "I'm sure it can be done but I don't know off hand how."


 > 
 > Whether we make a "release" of the system with the new build environment 
 > is a separate issue. I'd suggest we make a minor 'point' release just so 
 > everyone can get resynchronized at this point, but if others feel that it 
 > would just confuse users, I could live with that.
 > 
 > > Changing the build system is some internal reorgainzation issue and that's
 > > nothing the user cares about.
 > 
 > Yes, that's why I want to get it done now -- the monolithic build is going 
 > to make all future development harder for me (at least) and harder to get 
 > distributed (at least for Debian).  The sooner we get it done, the faster 
 > things can happen in the future.
 > 

This doesn't seem to be a universally shared position. 
To get as much as possible on the same page I'd like to 
see the issues individual groups have being addressed - 
with the outcome not anticipated beforehand.

Egbert.
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.