On czwartek 13 marzec 2003 02:52 pm, John Levon wrote: > On Thu, Mar 13, 2003 at 02:45:29PM -0500, Kuba Ober wrote: > > > Some of us don't want configuration management. > > > > The quality of software has been shown to be worse without one ;-) > > Quality is not and never was the most important thing with lyx. There > are some (rare) projects where it is ... not here...
I'm not claiming it's *the* most imporant thing. Nevertheless, it is somewhat important, right? > > > That's making unwarranted assumptions. Actually I'd like to avoid as > > > much administration as possible. That means not having to wait for > > > formal reviews, not having to open PRs before a fix can be accepted etc > > > > PR's? Gosh, it can be a one-liner! You have to put a changelog entry > > anyway, > > I was referring to e.g. Mozilla's model I don't know Mozilla's model. In Aegis, you can put as much or as little info into the change description as you feel like. You can even have anonymous changes. They are then only identified by number. It's just that if you work on one thing, it's beneficial even for your own sake to have different explorations/fixes/enhancements/etc. done in different changes -- say if you work on newest dialogs, it's worthwhile fixing say the few loosely related bugs that the new dialogs seem to uncover in a separate change. First of all that change will be small and it will be up for integration much quicker, and second of all this methodology has been asked over and over by Lars (as in: please send small, separate patches). That's almost like him asking to do things in separate changes, and have the integrated one at a time. I'm with Lars here: I have found that doing my own development like this, things are easier to keep under control, and I don't mix bugfixes with the feature enhacements that I happen to be working on at the time. Things are neatly separated, and the customers can get the fixes very quickly. The nice thing is, that if you feel like doing somebody else's wishes or bugs, you just use $ ael c to list all changes in current branch -- some of these changes will be in awaiting development state, so they are up for grabs. Or, if you feel like implementing your next killer feature, just create a change for it. Even better - if you have just an idea for a killer feature but no will/time to implement it, you can create a change ASAP. The development on it doesn't need to actually start right away. It can sit there, you can add more thoughts to the description, and finally you or somebody else could pick it up at a later time. Ah well, IIRC Aegis has a CVS repository migration tool, which automatically generates changes and branches for previous development work. It even has some intelligence to it (tries to decide which files went into each change - so sometimes it can merge commits if it decides they are somehow related). I never used it, but it's supposedly there. Cheers, Kuba Ober
